Summary

Fixes the 10-20s loading delay on large PostgreSQL tables reported in #519.

Root cause: Phase 2 automatically runs SELECT COUNT(*) FROM table on every table open. PostgreSQL COUNT(*) requires a full sequential scan (MVCC — each row's visibility must be checked). On a 3M-row table this takes 10-20+ seconds and blocks the shared driver connection.

Fix: Skip exact COUNT(*) when the approximate count (from pg_class.reltuples / information_schema.TABLE_ROWS) exceeds a configurable threshold. This is the industry-standard approach:

Changes

• Add countRowsIfEstimateLessThan setting (default: 100,000)
• Skip exact COUNT in both launchPhase2Work and launchPhase2Count when estimate >= threshold
• Add picker in Settings > Data Grid > Pagination (1K / 10K / 100K / 1M / Always count)
• Tables above threshold show ~N rows using the ~ prefix already supported by the status bar

Before/After

• Before: Open 3M-row table → wait 20s for COUNT(*) → "1-1000 of 3,000,000 rows"
• After: Open 3M-row table → instant → "1-1000 of ~3,000,000 rows"

Partially addresses #519

Test plan

• Open a large table (>100K rows) — should show ~N rows instantly, no delay
• Open a small table (<100K rows) — should still show exact count after Phase 2
• Settings > Data Grid > "Count rows if estimate less than" — verify picker works
• Set to "Always count" — verify exact COUNT runs for all tables
• Check non-SQL databases (Redis) — should continue using approximate counts